วิธีใช้ Claude Code แบบคนที่สร้างมันขึ้นมา

ผมเคยตั้งคำถามกับตัวเองว่าเราเห็นคนในช่อง Youtube สอนใช้ Claude Code เต็มไปหมดเลย แต่ที่อยากรู้จริงๆคือคนใน Anthropic ที่ทำมันขึ้นมาเนี่ย เข้าใช้มันยังไง แล้วก็ไปเจอคลิปจากช่อง Every ชื่อว่า “The Secrets of Claude Code From the Engineers Who Built It” ซึ่งเรียกว่าตรงเป๊ะๆ แต่คลิปยาวประมาณชั่วโมงสิบนาที ผมเลยจะขอสรุปเฉพาะส่วนที่เป็นการใช้งานของชาว ant ให้อ่านกันนะครับ

คลิปนี้เป็น podcast สัมภาษณ์คุณ Boris Cherny (หัวเรือแห่ง Claude Code) และ Cat Wu (PM) โดยเขาเริ่มจากการบอกว่าทีม Claude Code มีความได้เปรียบมากๆ ในการสร้าง tool ตัวนี้ เพราะเขามีวิศวกรใน Anthropic เป็นร้อยๆ คนที่ใช้เครื่องมือนี้ และคอย feedback ตลอด พวกเขาเรียกพิธีกรรมนี้ว่า “antfooding” (มาจาก Anthropic + dogfooding) พวกเขาได้ feedback จากทีมแทบจะทุกๆ 5 นาที ทำให้มีข้อมูลมาปรับปรุง tool ได้เยอะมาก

เทคนิคที่ชาว ant ใช้ Claude Code กัน #

อย่าใช้ one-shot แล้วหวังว่าจะได้ทุกสิ่งสมใจหวัง – ใช้ plan mode #

หลายคนมักจะมั่นใจว่า Claude Code จะเสกของออกมาให้ได้ภายในคำสั่งแค่ prompt เดียว แต่ในความเป็นจริงแล้วมันไม่ใช่เลย ยิ่งถ้าเป็นงานที่มีความซับซ้อน คุณควรใช้ plan mode เพื่อที่จะให้ Claude เขียนแผนออกมาทีละ step ก่อนลั่นเขียน code เสริมส่วนตัวสำหรับผมการอ่านแผนก่อนมันง่ายกว่าไปไล่อ่าน code ทีหลังนะ แล้วเราสามารถปรับแผนจนกว่าจะพอใจได้เรื่อยๆ ด้วย

ใช้ Claude Code settings เดียวกันทั้งทีมใน project #

ถ้าทั้งทีมของคุณใช้ Claude Code กันอยู่แล้ว ยัด .claude/settings.json ลงไปใน codebase ของ project ไปเลย แล้วตกลงกันทั้งทีมว่าอยากให้ Claude มัน skip permission ตรงไหน หรือ block งานไหน ก็ใส่ไปเลย จะได้อยู่ในมาตรฐานเดียวกันทั้งทีม

ใช้ Hook บังคับให้ Claude ทำงานให้เสร็จไม่งั้นไม่ให้หยุด #

หลายคนอ่านแล้ว “งง” ว่าเราบังคับได้หรอ คำตอบคือได้ครับ ด้วยการใช้ “stop hooks” Cherny บอกว่าเขาเห็น power user หลายคนเขียน hook ให้ไป trigger คำสั่ง test เอง หลังจาก Claude มันทำงานเสร็จ ซึ่งถ้า test ผ่านหมดพวกเขาถึงจะปล่อยให้มันจบการทำงาน แต่ถ้ามัน fail ขึ้นมาก็จะบอกให้ Claude แก้จนกว่าจะผ่าน (โดยที่ไม่ต้องมานั่งเฝ้าพิมพ์บอก)

เสก subagent มาตีกันเพื่อผลลัพธ์ที่ดีขึ้น #

Cherny ใช้ subagent (Claude instance หลายๆ ตัว ทำงานขนานกันไป) เพื่อตรวจสอบ code ก่อนที่จะถูก merge และเขาพบว่าการปล่อยให้มันตบตีกันเอง จะทำให้ได้ผลลัพธ์ที่ดีกว่า คำสั่ง /code-review ของเขาเองจะเสก subagent หลายๆ ตัวออกมาพร้อมกัน แต่ละตัวจะรับผิดชอบคนละอย่าง: ตัวนึงตรวจ style guidelines อีกตัวนึงไล่ดูประวัติของ project เพื่อเข้าใจว่าทำอะไรไปบ้าง และอีกตัวนึงจะหา flag bug ที่เห็นชัดๆ ซึ่งในรอบแรกก็มักจะเจอปัญหาได้จริงๆ แต่ก็มี false alarm ปนมาด้วย เพราะงั้นเขาเลยเสก subagent เพิ่มอีก 5 ตัวที่มีหน้าที่เฉพาะด้านเพื่อไปเจาะจงหา bug จากผลลัพธ์รอบแรก ท้ายที่สุดผลลัพธ์ก็จะเนียนตา และไร้ false alarm (ส่วนตัวผมว่าเราอ่านด้วยอีกรอบก็ดีนะ)

งาน migration คืองาน subagents #

ถึงการ migration อย่างเปลี่ยน version library หรือเปลี่ยน testing framework จะเป็นงานสำคัญ แต่การไล่แก้ code ทั้ง project ก็ไม่ใช่สิ่งที่โสภานัก ชาว Ant เลยเลือกที่จะใช้ main agent สร้าง to-do list แล้วสั่งให้มันเสก subagents แยกกันไปทำแต่ละ task ขนานกันไปเลย ซึ่งมันช่วยลดเวลาและประหยัดพลังคนไปได้เยอะ

ใช้ code เก่าและงานที่ทำไปให้เป็นประโยชน์ #

คุณ Wu บอกว่า power users มักจะให้ Claude ไปคุ้ยของใน project หรือประวัติใน version control ดูก่อนว่ามีอะไรที่เคยทำคล้ายๆ กันไปแล้วบ้าง จะได้ไม่ต้องสร้างใหม่ทั้งหมด (reinventing the wheel) ชาว ant บ้างคนถึงกับเขียน “diary entries” เพื่อบันทึกสิ่งที่ทำลงไปในแต่ละ task เพื่อบอกว่าอะไร work ไม่ work เก็บไว้เป็น log แล้วค่อยเสก agents มาอ่าน log พวกนี้เพื่อกลั่นเอา insights ของ project อีกที (ผมว่าอันนี้คล้ายๆ ทำ retrospective ของมนุษย์นะ)

Slash command ที่ใช้กันบ่อยๆ #

ทั้ง Cherny และ Wu เองก็มี custom slash command ที่ใช้กันบ่อยๆ ลองมาดูว่ามีอะไรบ้าง

• /commit: อันนี้ตรงไปตรงมา ไม่น่าจะต้องพูดเยอะ (ผมรู้คุณก็ใช้)
• /feature-dev: Cherny บอกว่าคำสั่งนี้ใช้ให้ agent ถามเขาว่ากำลังจะทำอะไรแบบ step-by-step (เหมือนเก็บ brief) แล้วค่อยสร้าง spec, เขียนแผนแบบละเอียด ไปจนถึง to-do list เลย
• /code-review: อย่างที่เล่าไปข้างบนว่าเสก subagent มาตบตีกันสักฝุ่น เพื่อให้มั่นใจว่า code พร้อม merge

สรุปแบบสั้นๆ #

ถ้าสังเกตจากใน podcast ชาว ant ไม่ได้ปล่อยให้ agent คิดเอง ตัดสินใจเองไปทั้งหมด แม้จะใช้ subagent ทำงานพร้อมกัน 5 ตัวก็ตาม แต่สุดท้ายคนที่อยู่หลัง keyboard ยังเป็นคนสุดท้ายที่ตัดสินใจ หรือไม่ก็เป็นคนแรกตัดสินใจว่าแผนไหนดีก่อนจะลั่นทุกอย่าง และการสร้าง custom command หรือ hook จะช่วยให้คุณประหยัดเวลา ควบคุมมาตรฐานของ code, style ได้ แค่ยอมเสียเวลาตกผลึกแล้วนั่งเขียน prompt ลงใน markdown ไฟล์เท่านั้นเอง

ดูคลิปเต็มๆ ได้ที่นี่: